Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add waiting state to showcase form #1605

Merged
merged 1 commit into from
May 23, 2024
Merged

Add waiting state to showcase form #1605

merged 1 commit into from
May 23, 2024

Conversation

dipamsen
Copy link
Member

See #1550

  • Adds "waiting" state to showcase form to prevent duplicate submission from double clicks
  • Style disabled button properly

cc @fturmel

Copy link

netlify bot commented May 19, 2024

Deploy Preview for codingtrain ready!

Name Link
🔨 Latest commit c0d04fa
🔍 Latest deploy log https://app.netlify.com/sites/codingtrain/deploys/6649792ca8a7fe0008fe572c
😎 Deploy Preview https://deploy-preview-1605--codingtrain.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@shiffman shiffman requested a review from fturmel May 19, 2024 16:06
@shiffman
Copy link
Member

Looks great, thank you @dipamsen! Tagging in @fturmel in case you have a chance to review!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the pseudo class :disabled instead of the attribute disabled? We might not need all the color variants specificity here either.

.rainbow:hover:not(:disabled) {
  background-position: left bottom;
  transition: background-position 4s ease-out;
}

button:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}

And well done on the negation here, I was wondering why you didn't use :enabled initially but this button component is sneaky and can end up being a <button> or a <Link> / <a> tag based on the props passed to it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought about this a bit more, and maybe the :not(:disabled) bit is too "clever" without a comment? Maybe something like this would be clearer/more self-documenting in the long run.

a.rainbow, button.rainbow:enabled {
  &:hover {
    background-position: left bottom;
    transition: background-position 4s ease-out;
  }
}

@@ -64,6 +64,6 @@
}
}

.submitBtn:hover {
.submitBtn:hover:not([disabled]) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we could actually use :enabled since it is always a button

@@ -429,7 +435,7 @@ const PassengerShowcaseForm = () => {
className={css.submitBtn}
onClick={onSubmit}
variant="purple"
disabled={submitted}
disabled={submitted !== 'not-submitted'}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit-pick but I find it hard to parse cognitively with the double (triple?) negative.

Maybe renaming the variable to submissionState and finding an alternate name for not-submitted state that doesn't contain a negative would help? What about undefined, would that read better?

submissionState === 'submitted'

disabled = !!submissionState

@fturmel
Copy link
Collaborator

fturmel commented May 19, 2024

Looks great, I agree!

Sorry for not shipping a fix myself after self-assigning the issue. I've been taking notes on additional improvements to the submission process and did not get a chance to code or share anything yet. More soon-ish!

@shiffman
Copy link
Member

Thank you @dipamsen, excited to merge this!

@shiffman shiffman merged commit 3d107b7 into main May 23, 2024
5 checks passed
@shiffman shiffman deleted the showcase-waiting branch May 23, 2024 14:31
@dipamsen
Copy link
Member Author

Oh whoops looks like the review comments were pending to be addressed...

@shiffman
Copy link
Member

Oh, sorry about that! Would you like me to revert or shall we just start a new branch? Apologies for this mistake!

@fturmel
Copy link
Collaborator

fturmel commented May 23, 2024

No worries, and no need to revert since the comments were more about minor code quality improvements. I can address them in an upcoming PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants